1. Field of the Invention
The present invention is directed to a system which displays and/or updates structured information such as the structured information that is stored in plural interrelated tables or in multipartite graphs like a structured relational database. In particular, the invention is directed to a system which displays either data from the structured information or an indication of interrelationships in the structure, wherein when data is displayed the data is filtered based on the interrelationships in the structure.
2. Description of the Related Art
Many different situations require the organization and storage of large amounts of information in computer accessible form so that the information may be retrieved and utilized efficiently. In one situation, for example, a hospital may need to store information concerning its medical staff, the times during which the staff members are normally available, and the names of staff members which may be substituted for an unavailable staff member. In another situation, a school may need to store information concerning its teaching staff, its student population, and the courses that the school offers and the students are enrolled in. Similar examples can be found in virtually any field, particularly business and scientific fields.
FIG. 25(a) is a simplified example of how information can be structured so as to facilitate its use. In FIG. 25(a), the structure is represented by a graph in which every entry (or mode) on the top row ("A", "B" and "C") is connected to every entry on the bottom row ("D", "E" and "F"). This structure can be represented in different but equivalent ways. For example, the graph in FIG. 25(b) has the same structure because the interconnections and interrelationships between the entries are the same. Likewise, the information displayed in FIG. 25(c) has the same structure as that in both FIGS. 25(a) and 25(b) although only the connections from node "B" are displayed (in the form of a pop-down window).
Structured information like that shown in FIGS. 25(a) through (c) has conventionally been stored in tables so that is can be used by computers. The structure of the information is known mathematically as a "multipartite graph" (FIGS. 25(a) through (c) are examples of "bi-partite graphs"), and the tables are partitions of the graph. Thus, referring to FIG. 25(a), the graph may be partitioned along the dotted line into two partitions, each of which may be stored in computer-readable tables. The rows of the table are considered to represent a record and the columns of the table are the individual data entries. Single records in a table may refer, for example, to people and the entries may be information about each person, such as name, address, telephone number, etc. When associating such tables with a graph, each set of nodes of the graph associate with a table, and the connection lines between two sets of nodes of the graph either are a table or are incorporated into a table.
As the number of interrelationships in the structured information increases, the complexity of the structure increases and many tables (or partitions) may be used to store the information. For example, in the situation where it is needed to store information about students and about teachers, it is not practical to store the information in a single table because the information needed to be stored for students is different than the information needed to be stored for teachers.
To handle large quantities of diverse yet related information, formalized computer structures such as relational databases have conventionally been used. (The invention can be implemented with any structured collection of information, relational databases being one such collection.) A relational database is a collection of individual tables in which each of the tables is only a subset of the total amount of information in the relational database. In the above example, a first table in the relational database might be a student table consisting of student name, identification number, dormitory assignments, etc.; and a second table in the relational database might be a course table consisting of course name, prerequisites, class time, place, etc. The relationship between students and courses is many-to-many, that is, many different students are enrolled in many different courses. Thus, a third, intermediary table is created which cross-references students to courses. This, then, provides two join fields, the student and the course, which together give the cross-reference of student-to-course.
The individual tables in a relational database are normally linked with one another through "join fields". In the above example, the join fields were the student identification number and the course number. Such a field links or joins the tables in the database. To correlate the information in a first table with the information in a second table, first the join field is extracted from the first table. Next, the join field is indexed to the second table by which it can be determined which entries in the two tables are associated. Usually, the indexing is via an intermediary, cross-reference, table (e.g., in "many-to-many" situations) but where an entry is joined directly into a table (e.g., a "many-to-one" situation) there is usually no need for an intermediate table.
Relational databases are effective to break complexly structured information into comprehensible and manageable units. Nevertheless, as the information grows and the complexity of the interrelationships increases, it becomes more and more difficult to find information and to use and/or modify the information effectively.
Assume, for example, that is desired to determine how a student can fulfill his minimum course requirements. This task requires correlation between a student, the course requirements for his core curriculum, the times and dates that the courses are offered in, the availability of the student during those times and dates, the availability of professors during those times and dates, etc. Each of these items of information is normally available in a separate table in a relational database, but owing to the complexity of the interrelationships between those tables, it has not heretofore been practical to correlate that information and to display it in useable form.
Or to consider the problem of adding or deleting a course. The course joins with the teachers giving the course, the usage of facilities, books, students taking courses, schedules for facilities, maintenance, people, etc. If one piece of information is added, changed, or modified, it is desirable to see all those changes wherever they are referenced, and to be able to request that those changes propagate through the graph appropriately. Thus, when displaying the courses a student is taking, a deleted course should not be displayed and the deletion should not cause an error.